Skip to main content
Expert Talk
Amakomaya — Aamako Maya Apps Pvt. Ltd.

Architecture Patterns

A pattern is a solution shape that recurs, with a known set of trade-offs. Recognising the pattern saves you from rediscovering the trade-offs.

Each entry below states the problem, the structure, when to use it and — the part usually missing — when not to. The detailed pages cover the patterns whose trade-offs decide national architectures.

Exchange patterns​

Centralised HIE​

Problem: clinical data is scattered across systems and unavailable when a patient presents elsewhere. Structure: sources push to a central repository; consumers query it. Use when there is a central mandate, edge connectivity is unreliable, and population analytics matters. Avoid when the law or institutional politics prohibit central storage of identifiable data.

Federated HIE​

Structure: a record locator plus query fan-out to sources at read time. Use when sources must retain custody and connectivity is reliable. Avoid when sources cannot guarantee availability, or population analytics is a primary goal.

Hybrid HIE​

Structure: central identity, index and summary; detail fetched on demand. Use when — usually. This is the pattern most national architectures converge on. Avoid when you cannot operate two mechanisms.

Shared health record​

Problem: no single view of a patient across encounters and providers. Structure: a normalised longitudinal store fed by point-of-service systems. Use when at least two systems will both write to and read from it. Avoid when nobody reads from it yet — you are building a write-only database. See business domain services.

Document exchange​

Problem: a receiving clinician needs a coherent, attested snapshot. Structure: documents published to a repository, indexed in a registry, and retrieved (IHE XDS/MHD; content in CDA or FHIR). Use when referral, discharge and legal attestation dominate. Avoid when the need is to answer specific data questions — you would have to open documents to find them.

Patient-mediated exchange​

Problem: no lawful or practical provider-to-provider channel exists. Structure: the patient authorises access via an app, or carries a verifiable summary. Use when mobility, cross-border care or consent legitimacy dominate. Avoid when the patient cannot participate — emergencies, and populations without devices.

Event-driven interoperability​

Problem: many consumers need to know when something happens. Structure: sources publish events; subscribers consume from a broker. Use when surveillance, care coordination or index maintenance need timeliness with loose coupling. Avoid when you cannot make consumers idempotent, or the team cannot operate a broker.

Integration patterns​

Interoperability layer / integration engine​

Problem: point-to-point integration cost grows quadratically. Structure: one mediating component handles authentication, routing, transformation, orchestration and audit. Use when more than about four systems must exchange. Avoid when there are two systems and no plans for more — you would be operating infrastructure to solve a problem you do not have. See interoperability layer.

FHIR facade​

Problem: a system holds useful data but cannot be replaced or rewritten. Structure: a FHIR API in front of the existing store, translating on demand. Use when you need standards-based access without a migration. Avoid when the underlying model cannot express what the profile requires — the facade will lie.

Anti-corruption layer​

Problem: a legacy system's model would contaminate the new architecture. Structure: an adapter that translates between the two models and belongs to neither. Use when integrating anything you do not control. Avoid when the two models genuinely agree — the layer is then pure cost.

API gateway​

Problem: cross-cutting concerns duplicated across services. Structure: a single ingress handling authentication, routing, rate limiting and logging. Use when multiple services face external consumers. Avoid when treated as a substitute for an interoperability layer — a gateway does not do identity resolution, terminology translation or orchestration.

Registry-first architecture​

Problem: exchange built before shared identity has to be rebuilt. Structure: establish facility, client and provider registries before building exchange. Use when starting a national programme. Essentially always. Avoid when — no credible case. The sequencing is in registries.

Data patterns​

CQRS (command–query responsibility segregation)​

Problem: the write model and the read model have incompatible shapes. Structure: separate paths — normalised writes, denormalised read views. Use when clinical capture and population reporting contend for the same store. Avoid when the added complexity exceeds the contention — most single-facility systems.

Event sourcing​

Problem: you need to know not just the current state but how it was reached. Structure: an append-only log of events is the source of truth; state is derived. Use when auditability and reconstruction are first-class requirements. Avoid when the team has not operated one before — schema evolution and replay are genuinely hard, and health data retention is measured in decades.

Saga​

Problem: a multi-step transaction across services cannot be atomic. Structure: a sequence of local transactions with compensating actions. Use when orchestrating across registries and repositories where a partial failure must be unwound. Avoid when a compensating action is not actually possible — you cannot un-tell a clinician something.

Data lakehouse​

Problem: analytics contends with clinical operations. Structure: raw, conformed and mart layers over object storage with transactional table formats. Use when building a new analytics platform. See data architecture. Avoid when there is no data catalogue or ownership model — it becomes a swamp.

Terminology service​

Problem: code mappings hard-coded across applications, diverging silently. Structure: a service holding code systems, value sets and maps, consulted at runtime. Use when more than one system codes the same data. Avoid when — none, though the sizing varies. See terminology services.

Edge and resilience patterns​

Offline-first​

Problem: connectivity is intermittent and care cannot wait. Structure: a local store of record, a sync protocol, and explicit conflict resolution. Use when community health workers, rural facilities or outreach are in scope. Avoid when connectivity is genuinely reliable — the complexity is substantial.

Store-and-forward​

Problem: the central service is unavailable when data is created. Structure: queue locally, transmit when possible, with retry and backoff. Use when any edge system depends on a central service. Effectively always. Avoid when the data is only valuable in real time — then fail loudly instead of queueing silently.

Circuit breaker​

Problem: one slow dependency exhausts the caller's resources. Structure: trip after repeated failures, fail fast, probe for recovery. Use when the interoperability layer depends on several downstream services. Avoid when a fast failure is worse than a slow success — some clinical lookups genuinely justify waiting.

Degraded mode​

Problem: a central outage stops care. Structure: defined reduced functionality — cached registries, local read-only records, printed summaries, paper fallback with reconciliation. Use when any system is on the clinical critical path. Avoid when — no case. Its absence is a design defect.

AI patterns​

All Tier 4 unless the integration mechanism is a Tier 1 standard. See AI architecture.

Human-in-the-loop​

Problem: model outputs may be wrong in ways that harm patients. Structure: the model proposes; a clinician disposes; the override is recorded. Use when anything model-derived reaches clinical decision-making. Avoid when — no case, in clinical contexts.

Retrieval-augmented generation over clinical knowledge​

Problem: clinicians cannot find the relevant passage in national guidance. Structure: retrieval over a governed, versioned corpus; generation with specific citations. Use when the corpus is curated and the output is reference material. Avoid when the corpus is ungoverned, or the question is patient-specific clinical advice.

Model registry and monitoring​

Problem: models degrade and nobody notices. Structure: versioned models with lineage; monitored inputs, outputs and subgroup performance; a defined stopping rule. Use when any model runs in production. Avoid when — no case.

How to use a pattern​

  1. State the problem in your own context before choosing.
  2. Check the avoid when conditions honestly — most misapplied patterns fail on a condition that was known at the outset and ignored.
  3. Record the choice as an ADR, including the alternatives.
  4. Name the pattern in the design so the next team recognises it.

References​

Last updated on